Guide to Core Web Vitals for SEOs and Developers

These metrics center on when certain events complete, including what is interactive or visually affected as these events take place, while pages load until a point of stability relative to user experience. That means score values can change as users interact with your page. You achieve better scores when events occur faster along stop-watch time intervals.

Performance metrics for each Web Vital statistic is graded according to three outcomes:

• Good (passes)
• Needs Improvement
• Fail

The current metrics are:

• Largest Contentful Paint (LCP). The time interval between the start of a page load to when the largest image or text block in a user’s viewport is fully rendered. You might see the score change as your page loads and when content is visible but the largest node is still in the backlog yet to be displayed. This gets more noticeable on throttled connection speeds.
• First Input Delay (FID). The amount of time it takes for a page to be ready for user interactivity, meaning that as pages are assembling how long does it take for the page to respond to clicks, scrolls, or keyboard input processing their corresponding event handlers. User interaction can be significantly delayed by main thread-blocking script tasks.
• Cumulative Layout Shift (CLS). The measured distance and fraction of the viewport which shifts due to DOM manipulation or the lack of dimension attributes for major media elements. When we fail to define the dimensions for our hero images, for example, text on our pages first appears only to be displaced, causing a disruptive content layout “shift” for our users.

Long-time users of PageSpeed Insights (PSI) may be familiar with similar metrics, many of which are going to stick around, although perhaps not all of them. Core Web Vitals represent a culmination of these other metrics and come out of the Developer Experience complexity with them. The simplicity of Web Vitals are meant to cut through the noise for welcomed clarity and fewer, grander metrics to follow.

Google plans to limit updates to annual Web Vitals version releases in order to prevent the goal posts from moving too frequently for site developers and SEOs, but you can expect Google to add new metrics over time. It looks like the next addition is going to measure page animations; that metric is under development and won’t be introduced this year, for example.

How to analyze mobile and desktop Web Vitals scores

You get independent Web Vitals scores between mobile (phone) devices or desktop / laptop. In some tools you can specify which device category you want to run a query or test, and you can switch between them when both are available in a tool like Google PageSpeed Insights. PageSpeed Insights defaults to mobile stats, so you’ll need to switch to the desktop tab in order to see the difference in a page’s desktop versus mobile scores.

Google has added Core Web Vitals metrics to Search Console reporting when Chrome User Experience data is available. If you’re accessing Web Vitals scores within Search Console, the dashboard displays both device categories with scores across URLs covered by your indexing. You can drill down into groups of pages that are indicated to have problems.

As part of its Chrome User Experience Report (CrUX), Google exposes field data from over 18 million websites that have tallied enough statistics to report Web Vitals. The data is housed at Google’s BigQuery service, where you can query statistics from these websites going back several years. Updates are ongoing and available the second Tuesday of each month, following accumulation.

In order to see mobile and desktop scores using the new CrUX report, you’ll need ‘phone’ or ‘desktop’ as device form factors in your SQL statements. Interestingly, ‘mobile’ doesn’t work as it’s not a column and ‘tablet’ works only rarely due to the scarcity of the specified data. Tablet data can be seen in queries for the Google origin (domain), for example, but you aren’t going to see it for quieter sites.

Understanding lab vs. field data

Conditions can result in wildly varying scores, and scores can literally change as you navigate pages. It’s important to understand how each score is tabulated, given a certain environment.

You can only truly interpret results after you first determine whether you’re looking at lab or field data. Web Vitals “lab” data are collected via browser API as part of page load event timers and mathematical approximations simulating user interactivity, whereas “field” data is made up of the same metrics collected from actual user experiences navigating your pages with the resulting event timer values being transmitted to a repository.

Both SEO practitioners and developers can access lab data in real-time using PSI, WebPageTest, Chrome Dev Tools, and through a new ‘Web Vitals’ Chrome browser extension. PSI and WebPageTest tallies your scores from page load events and approximates page interactivity delays by counting up thread-blocking script task times.

Lab data tools are incredibly useful in your workflow towards reporting and improving scores. These should make up part of your TechSEO arsenal. For developers, if only a handful of templates power your website, then these lab data may be all that you regularly need, unless you start seeing problems in field data that catches you off-guard.

You can introduce the Web Vitals JavaScript library to your workflow and testing pipeline. Available via CDN, the library can be included in production HTML and written to transmit independently gathered field data to where you want to collate them for reports. Example code demonstrates how to do so for transmitting scores to Google Analytics.

Lighthouse also comes with various access points which can be useful in your development workflow and it includes several additional tests that can help ensure your adherence to modern web standards. Lighthouse can help you debug situations where you are troubleshooting Web Vitals problems.

Comparing lab results with field data. Modern browsers beginning with Chrome measure how users actually experience your website in the wild via builtin JavaScript API. You can access these with any JavaScript, or choose one of Google’s libraries modified to your requirements. Google collects and, as noted, exposes field data from Chrome users for its CrUX report and at times using the same browser APIs.

There are a few different ways to access or visualize CrUX data. You can utilize connectors from BigQuery output to other Google services for generating dashboards, such as a prebuilt connector for DataStudio.

It’s easier to access field data when you’ve confirmed that your site has field data in CrUX, by verifying ownership of your website with Google Search Console. There, the dashboard displays field data with an interface that allows you to drill down with clicks instead of writing SQL queries.

Alternatively, you can simply use PSI which provides you data going back up to 28 days. The API that drives that quick-check recency report is also an independent open source JavaScript library which you can bring into your development workflow, or use to power an app dashboard. It can serve as a standalone app where, for demonstration, a developer already created a slick frontend for it.

Troubleshooting Web Vitals reporting

Due to the dynamic nature of some of the timings and how they’re collected, you’re always going to need to verify lab data by correlating field data so you can debug discrepancies. For example, subsequent page loads can vary your result values when using the Web Vitals Extension. This can happen for a couple of reasons.

Your browser is able to assemble resources faster on refresh by virtue of utilizing its own cache reserve. Additionally, the extension is able to accumulate interactive values as you navigate the page in a way that is useful for approximating real-world field data rather than calculating a score by adding up thread-blocking script task timings.

For more accurate local results using the Web Vitals Extension and Chrome Dev Tools remember to empty your cache data or bypass it with shift-refresh when moving fast with the web browser in your workflow. Another tip is to load ‘about:blank’ before starting a performance recording session in Dev Tools for a clean start to the report.

Ideally, lab and field scores don’t differ too much without a good reason. Whenever you make significant changes, your lab results are going to be ahead of your field data. That means if you see failing tests in the field and you’ve improved lab scores to pass, you either need to be patient for field data to catch up or push field data independently to Analytics to verify it.

You might imagine the trickiest field data score to emulate locally would be CLS. This isn’t necessarily the case. You can set an option to stick an overlay of Web Vitals using the Chrome Extension where, when you interact with the page, you can watch score changes as you navigate.

This works for FID as well. The FID score starts empty. With the first page interaction (click, scroll, or keyboard input), the timings of thread-blocking tasks are added to that moment — which becomes your score.

Finally, the highly detailed information in Chrome Dev Tools lets you troubleshoot CLS to a fine-grained level with performance recording and playback. Look for the “Experience” section that outputs CLS shifts in the recording. There is also a setting for highlighting shifts in the display using a blue flash that wraps elements as they shift and add to your score.

Tool time

PageSpeed Insights. Your first stop measuring Web Vitals should be PageSpeed Insights. You get both lab data and field data (when available) in one report. You also get several other metrics largely related to improving failing pages, particularly findings that affect the speed of a page and downloading its assets.

Web Vitals Chrome Extension. Using the Chrome extension you can access Web Vitals on page load, and as discussed, you can interact with the page to troubleshoot in case you have First Input Delay and or Content Layout Shift problems. It’s also available to you page-to-page as you browse websites.

WebPageTest. With this independent testing tool you can configure your approach with a variety of conditions. Built by Google engineers who are part of the Chromium team, the information is as authoritative as anything you get from Google itself and makes RESTful APIs available.

Google Search Console. If you haven’t already verified ownership of your website to use Google Search Console, then you should go and do so for help drilling down into problem areas with pages that are failing out in the field — assuming you are showing in CrUX. You can drill down to locate groups of pages with similar problems. Ultimately it links you to PageSpeed Insights.

Web Vitals JavaScript APIs. Use JavaScript to access the metrics directly from the browser and transmit them to a repository of your choice. Alternatively, you can introduce the test to your development process and ensure that changes you make aren’t going to negatively affect your scores after you push to production.

Chrome Dev Tools. Chrome itself provides the ultimate set of tools for discovering or tracing back problems using the highly detailed information available in reports and page load recordings in the Performance tab. The extensive array of tools and endless switches and options are ideal for the most exacting optimization work.